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INTERWORKING OF IP VOICE WITH ATM VOICE USING SERVER- 
BASED CONTROL 

FIELD OF THE INVENTION 

[0001] The present invention relates generally to packet-based telephony, and in 
particular to apparatuses and methods for the interworking of two or more non- 
compatible packet-based voice technologies, 

BACKGROUND OF THE INVENTION 

[0002] Telephone carriers are deploying various packet-based voice technologies 
such as Real-time Transport Protocol/Internet Protocol (RTP/IP) and Asynchronous 
Transfer Mode Adaptation Layer 2 (ATM/AAL2). These technologies do not interwork 
seamlessly. Currently deployed call agents, software systems that establish the 
connections across packet-based voice network, do not have the capability to co-ordinate 
the conversion of different types of packet-based data. Two different types of packet- 
based voice technologies, for example VoIP and VoATM can be made to interwork with 
each other with a public switched telephone network (PSTN) between them. However, 
the PSTN middleman necessitates costly and inefficient conversion into outdated time 
division multiplexing (TDM) format and thence to another packet-based format. This 
lack of interworking is at the bearer and control levels. As a result, there are various, 
pioneering packet "islands" that use the outdated, PSTN as the glue, thereby annulling the 
advantages of packet-based voice technology over large geographical areas. Using the 
PSTN also incurs signal degradation because the PSTN uses only non-compressed voice 
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signals. Packet networks may use compressed signals that need to be converted into non- 
compressed format and then converted back into compressed format. 
[0003] Figure 1 is a block diagram depicting a typical conversion from an IP network 
to an ATM network. In the telecommunications network 100 shown in Figure 1, 
telephonic data is received at voice over IP (VoIP) edge gateway 102. This data may be 
received from individual telephones, a private telephone network such as a private branch 
exchange (PBX), a data modem, or a fax machine, among others. Edge gateway 102 is a 
combination of software and hardware that bridges the gap between the telephone 
network and the DP network. Edge gateway 102 may be integrated into the telephone or 
PBX. The telephonic data is then routed over IP network 104 to trunk gateway 106. 
Establishment of the connection between the VoIP edge gateway 102 and trunk gateway 
106 is controlled by one, or more, call agents 108. The call agent 108 establishes the IP 
session between the VoIP edge gateway 102 and the trunk gateway 106, and coordinates 
the conversion of data from IP format to TDM format. The data is transmitted over TDM 
trunk lines 109 to a network of PSTN switches 1 10. The TDM trunk lines may be, for 
example, Tl lines. The data is now transmitted over TDM trunk lines 1 1 1 to trunk 
gateway 112. The connection between the trunk gateway 112 and the voice over ATM 
(VoATM) edge gateway 116 is controlled by one, or more, call agents 118. Further, call 
agents 108 and 118 can communicate with each other and with the PSTN switches 
through a Signaling System 7 (SS7) control network. The call agent 118 initiates the 
establishment of an ATM connection, and coordinates the conversion of data from TDM 
format to ATM format. The data is routed through ATM network 1 14 to VoATM edge 
gateway 116. From VoATM gateway 1 16 the telephonic data is transmitted to its 
destination telephone or PBX, for example. 



[0004] The routing of packet-based voice data through a PSTN defeats one of the 
advantages of packet-based voice transmission, which is that the voice data can be 
compressed, thereby reducing bandwidth and cost. No such voice compression is 
possible in a PSTN; the telephonic data must be decompressed upon entering the PSTN 
and, recompressed upon exiting the PSTN. By routing VoIP data through a PSTN to an 
ATM network, this major advantage of packet-based voice technology is negated. 
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SUMMARY OF THE INVENTION 

[0005] A method and apparatus is described for converting packet-based voice 

data of a first format directly to packet-based voice data of a second format. Data from 
two networks using non-compatible packet-based voice technologies, for example, 
VoATM and VoIP, is interworked for direct conversion. A connection is set between an 
edge gateway of a first voice packet network, having data in a first format, and an 
interworking unit (TWU). Another connection is set up between this IWU and an edge 
gateway of a second voice packet network, having data in the second format. The IWU is 
controlled by a single call agent that is able to co-ordinate the conversion, at the IWU, 
between the two packet formats. Because it has this capability, this call agent is also 
called the "conversion server". This call agent may be identical to the call agent used to 
control one or both edge gateways that use different packet based technologies. 
[0006] Other features and advantages of the present invention will be apparent 

from the accompanying drawings, and from the detailed description, which follows 
below. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

[0007] The present invention is illustrated by way of example and not intended to 

be limited by the figures of the accompanying drawings in which like references indicate 
similar elements and in which: 

[0008] Figure 1 is a block diagram depicting a typical conversion from an IP 

network to an ATM network in accordance with the prior art; 

[0009] Figures 2 and 3 are block diagrams depicting the conversion of IP data to 

ATM data in accordance with the present invention; 

[0010] Figure 4 is a block diagram of an IWU in accordance with the present 

invention; and 

[0011] Figure 5 is a process flow diagram according to one embodiment of the 

present invention. 



6 



DETAILED DESCRIPTION 

[0012] An embodiment of the present invention will provide a simple method of 

interworking the call control and voice information of different voice packet networks 
(e.g., VoIP data with VoATM data). This is accomplished by taking advantage of the 
call-agent based complex call handling software to interwork the control information 
native to each of the packet networks. This software, called the "conversion server" 
software herein, provides a conversion between ATM parameters and IP parameters (e.g., 
AAL-2 profiles versus RTP/AVP payload types). The "conversion server" software also 
controls the IP- ATM conversion function that is modeled in terms of packet-to-packet 
endpoints within the Interworking Unit (IWU). If necessary, the interworking unit (IWU) 
accepts ATM switched virtual circuit signaling or AAL International 
Telecommunications Union Telecommunications (ITU) standard Q.2630.1 signaling to 
establish a bearer path in the ATM network and to bind into an RTP port on the other side 
of the Interworking Unit (IWU). 

[0013] In one embodiment the ATM data is ATM Adaptation Layer Type 2 

(AAL-2) data. In one embodiment the call agent that manages the VoATM network has 
the "conversion server" software and is used to interwork the VoATM and VoIP control 
information. This call agent, that has conversion capability, may be selected by the 
originating call agent based on destination number. In an alternative embodiment, the 
call agent that manages the VoIP network has the "conversion server" software and is 
used to interwork the VoATM and VoIP control information. 

[0014] An intended advantage of one embodiment of the present invention is to 

provide user-transparent end-to-end code/profile negotiation that spans the IP and ATM 
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networks. Another intended advantage is to provide the ability to access an adjacent 
packet network that uses a different technology (e.g., IP, ATM/PNNI, ATM/AAL2) with 
a minimal number of endpoints and links. Another intended advantage of one 
embodiment of the present invention is to provide the ability to interwork various packet- 
based voice technologies without recourse to legacy communication networks (e.g., 
PSTN). 

[0015] Figures 2 and 3 are block diagrams depicting the conversion of voice 

packet data from one voice packet data format to another in accordance with the present 
invention. Both figures depict the conversion of telephonic data between VoIP and 
VoATM and vice versa. In Figure 2, the packet conversion function in the IWU is 
controlled by the VoIP call agent. In Figure 3, the packet conversion function in the 
IWU is controlled by the VoATM call agent. The following process describes conversion 
between VoATM and VoIP as implemented by the system illustrated in Figure 2. The 
conversion process implemented by the system of Figure 3 is analogous. 
[0016] The telecommunications system 200 shown in Figure 2 includes a 

VoATM edge network 206. Telephonic data from, for example, a PBX, is received at a 
VoATM edge device of VoATM edge network 206, i.e., the VoATM edge device 
receives a set-up message. The VoATM edge network is coupled to a VoATM call agent 
208 that sends signals to the VoATM edge device in order to create a connection. In 
response, the VoATM edge gateway device sends the VoATM call agent 208 a session 
descriptor that includes such information as ATM address and profile information. The 
VoATM call agent 208 is linked to a VoIP call agent 214 that interfaces an interworking 
unit (IWU) 212. The IWU 212 is coupled to the ATM network 210 and to the IP edge 
network 216. The IWU 212 is described in greater detail below. The VoIP call agent 214 
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receives the session descriptor from the VoATM call agent 208. The "conversion server" 
function in the VoIP call agent 214 converts VoATM-specific parameters (such as AAL2 
profiles) in this session descriptor into VoIP-specific parameters (such as codecs). It 
selects a packet-to-packet endpoint in the IWU 212 as the resource responsible for 
converting voice traffic between the VoATM and VoIP formats. It passes these derived 
(converted) VoIP-specific parameters, along with the original session descriptor, to an 
interworking unit (IWU) 212. The IWU 212 responds to the VoIP call agent 214 with its 
own session descriptor including its own IP address and preferred encoding schemes. 
Simultaneously, the IWU 212 uses the ATM address information forwarded by the VoIP 
call agent 214 to set-up an ATM path [such as a Switched Virtual Circuit (SVC) or an 
AAL2 channel] to the VoATM edge device of VoATM edge network 206. The VoIP call 
agent 214 then establishes a connection between the IWU and a VoIP edge gateway 
device of VoIP edge network 216. The VoIP edge gateway device sends its session 
descriptor to the VoIP call agent 214. The "conversion server" function in the VoIP call 
agent 214 converts VoIP-specific parameters (such as the encoding scheme selected for 
the connection) in this session descriptor into VoATM-specific parameters (such as 
profile). It passes the derived (converted) VoATM-specific parameters, along with the 
original session descriptor from the VoIP edge network 216, to IWU 212. As an 
acknowledgement, IWU indicates its acceptance of the selected AAL2 profile and the 
selected, inter-working RTP codec/payload type . The conversion server function creates 
an ATM-specific SDP descriptor from the information provided by the IP edge network 
216 and the IWU 212, and forwards it to the VoATM call agent 208 that forwards it to 
the ATM edge gateway device. At this point a fully characterized end-to-end connection 
has been established between an ATM segment and an IP segment. 
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[0017] Figure 4 illustrates the functionality of an IWU 400 in accordance with 

one embodiment. The conversion of VoIP to VoATM begins at operation 405 in which 
voice data is received as VoIP at the physical layer. The physical layer may be, for 
example, synchronous optical network data (SONET). The AAL-5 data is extracted from 
the physical layer at operation 410. From this data, the bearer signaling information is 
extracted at operation 450, the call agent information is extracted at operation 445, and 
the VoRTP information is extracted at operation 415. At operation 420, the voice 
samples are extracted from the VoRTP information and stored to buffer memory. At 
operation 425 the voice samples are formatted as AAL-1 or AAL-2 protocol data units 
(PDUs). The formatting may be accomplished in accordance with ATM Forum - Voice 
and Telephony over ATM specification 78 for AAL-1 data, and International 
Telecommunications Union specification 1.366.2 for AAL-2 data. At operation 430 the 
data is reformatted as ATM cells. At operation 435 the ATM cells are used to create a 
VoATM data stream, and at operation 440 the VoATM data is output to the appropriate 
physical layer (e.g., SONET). 

[0018] The call agent information that contains the media gateway control 

protocol (MGCP) and session description protocol (SDP) is forwarded to the call agent 
message processor at operation 455. The call agent message processor interfaces to the 
VoIP call agent. In an alternative embodiment the call agent message processor 
interfaces to the VoATM call agent. The choice of the call agent is based on whether the 
"conversion server" software is located in the VoIP or VoATM call agents. As shown in 
Figures 2 and 3, the IWU has an interface with the VoIP call agent (Figure 2), or with 
the VoATM call agent (Figure 3). The Interworking Unit interfaces to a call agent that 
has the conversion server software built into it. 
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[0019] The call agent message processor interprets the SDP. The "conversion 

server" function in the call agent is responsible for deriving IP parameters from an ATM 
SDP, and the ATM parameters from an IP SDP. The "conversion server" function in the 
call agent is also responsible for identifying the packet relay endpoint to be used. The 
RTP port information in the SDP, the packet relay endpoint identifier and the virtual 
circuit identifier (VCI) or AAL2 channel identifier (CID) that it is mapped into is stored 
in the form of packet relay endpoint associations at operation 470. This information 
controls how the RTP streams flow into the VoATM streams and vice versa. 
[0020] At operation 460, the bearer signaling information, extracted from the 

AAL-5 data at operation 450, is forwarded to the bearer signaling message processor. 
Based on the MGCP and the SDP messages, a bearer path, for example, a switched 
virtual circuit (SVC), or an AAL-2 path, is established. When the path is established a 
status indication is sent. The bearer signaling is described in more detail, below, in 
reference to Figure 5. 

[0021] There is no separate conversion of VoATM to VoIP. The path established 

through the Intwerworking Unit (IWU) is a bi-directional path. Whenever there is 
VoATM to VoIP conversion, there is VoIP to VoATM conversion, and vice versa. 
[0022] The following describes a VoATM-VoIP call set-up using an ATM core 

network as shown in Figure 2. Depending on the signaling format used by the PBX, the 
ATM edge gateway forwards a set-up message from the PBX to the VoATM call agent, 
or sends event notifications indicating off-hook status and the dialed number. On the 
basis of the dialed number, the VoATM call agent determines that it is necessary to use 
the VoIP call agent in routing the call. The VoATM call agent sends a connection 
establishment command to the VoATM edge gateway. The connection establishment 
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command contains a list of coder-decoders (codecs) encapsulated in local connection 
options (LCOs). The list of codecs represents available encoding schemes that may 
involve compression/decompression. The ATM edge gateway chooses one or more of 
the alternatives, provided in the LCO, and encapsulates that information in a SDP 
descriptor (SDP1). Within SDP1, the ATM edge gateway also includes its identification 
information including its own ATM address information. The address information may 
typically include an nsap address, a vcci, and a cid. SDP1 may also include a four octet 
identifier known as the Backbone Network Connection Identifier (BNC-ID) which is used 
to identify which ATM path is associated with which voice call. SDP1 also includes 
ATM specific profile information that describes which codecs are to be used. The 
process is described from this point forward by Figure 5. Figure 5 is a process flow 
diagram according to one embodiment of the present invention. Process 500, shown in 
Figure 5, begins at operation 505 in which the information in SDP1 is sent to the 
VoATM call agent that forwards the information to the VoIP call agent. At operation 510 
the VoIP call agent uses the information in SDP1 to generate IP codec parameters and 
packetization -time parameters. The VoIP call agent encapsulates this information as 
SDP2. SDP2 is SDP1 as translated by the VoIP call agent. The VoIP call agent forwards 
SDP1 and SDP2 to the IWU that generates its own SDP (SDP3) in response, operation 
515. SDP 3 includes the IWU's own IP address and IWU preferences for RTP port 
number, codecs, and packetization period. If necessary, the IWU uses the information in 
SDP1 (such as the NSAP address and the BNC-ID) to set up an ATM path such as a 
Switched Virtual Circuit (SVC) or an AAL2 channel to the ATM edge gateway, operation 
520. This uses SVC signaling (such as Private Network-Node Interface signaling defined 
by the ATM forum) or the Q.2630.1 signaling defined by the International 
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Telecommunications Union (ITU). At the same time, SDP3 is forwarded to the IP edge 
gateway that provides the VoIP call agent with its own IP address, RTP port number, and 
chosen codec in operation 525 as SDP4. The VoIP call agent converts the IP-specific 
parameters in SDP4 into ATM form (e.g. the chosen codec into a chosen profile), 
packages the converted information into SDP5 and forwards both SDP4 and SDP5 to the 
TWU in operation 530. 

[0023] At this point the connection between the IWU and the IP edge gateway has 

been set, i.e., the IWU and the IP edge gateway know the IP addresses and RTP port 
numbers of each other. 

[0024] At operation 535 the rWU sends the VoIP call agent an SDP descriptor, 

SDP6, which is forwarded to the ATM edge gateway. This includes the selected AAL2 
profile for the connection that was derived in operation 520. At operation 540 the VoIP 
call agent sends SDP6 through to the VoATM edge gateway. This allows the VoATM 
edge gateway to know which profile to use. The ATM path to be used is conveyed 
through the BNC-ID in the signaling flows referred to in operation 520. At this point an 
end-to-end connection via the VoATM and VoIP networks has taken place. 
[0025] In the foregoing specification, the invention has been described with 

reference to specific exemplary embodiments thereof. It will, however, be evident that 
various modifications and changes may be made thereto without departing from the 
broader spirit and scope of the invention as set forth in the appended claims. The 
specification and drawings are, accordingly, to be regarded in an illustrative sense rather 
than a restrictive sense. 
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